ADR-32: Logical permissions #145
Conversation
Signed-off-by: Byron Ruth <b@devel.io>
Signed-off-by: Byron Ruth <b@devel.io>
| allow: [ | ||
| "inbox(operator)", | ||
| "js-stream-operator(EVENTS)", | ||
| ] |
There was a problem hiding this comment.
Maybe also need to cover how this maps to the imports and export syntax while we are at it, sub represent either a stream or service.
Like being able to define that reading info about consumer and streams is ok from the other account but not ok to create, something like:
exports: [{stream: "foo"}, { jetstream: { streams: [ { name: EVENTS, export: [stream-info, consumer-info] }]There was a problem hiding this comment.
Indeed. Fundamentally, these permissions can be thought of as functions that expand to one or more subjects js-stream-info(EVENTS) → $JS.API.STREAM.INFO.EVENTS. I thought about having these permissions able to be intermingled with standard subjects. If that is the case, the ambiguity of subject vs perm needs to be removed, so some kind of prefix character could help differentiate, such as @ or whatever.
Then you could have something like:
exports: [
{service: "@js-stream-info(EVENTS)"},
]
The implicit pub/sub information would really only apply in the user permissions context.
| allow: [ | ||
| "inbox(joe)", | ||
| "pub(services.*)", | ||
| ] |
There was a problem hiding this comment.
this syntax is nice, I was thinking of granular permission like below but seems very verbose:
permissions = {
# Can publish to stream
publish: { allow = ["a"] }
# Granual permissions for JetStream features
jetstream: {
streams { EVENTS = { allow: [ stream-info ], deny: [add-stream, delete-stream] } }
kv { TEST = { allow: [ put, del], deny: [ destroy-kv ] }
object-store { allow: [...] }
}
}
}There was a problem hiding this comment.
I like the structure that your example provides which provides namespacing (as I am doing js- and kv-). A future state I considered was user-defined permissions which may break the structure. For example, if a new key called roles within an account is defined, you could declare new mappings off the primitive logical permissions the NATS server provides.
There was a problem hiding this comment.
It should be possible to subset keys/object names on kv/object store - currently object store doesn't expose data chunks in a way that can be clamped.
|
Looks really cool! Decouples the configuration from the concrete subjects. What I'm wondering, how would this work for consuming a stream/watching a KV? I'm thinking that would be a combination of several permissions, for example: However, that would still require you to know the relationship between multiple permissions, as those need to be combined in order to: create an ephemeral consumer, start consuming from it, and maybe at some point delete the consumer, etc. I like the syntax of @wallyqs as well, albeit a bit more verbose, it might be more concise with the addition of watching a stream for example: permissions = {
jetstream: {
streams { EVENTS = { allow: [ watch-ephemeral ] }}
}
}With a short-hand like |
No description provided.